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(54) System for generating composite packets 



(57) This invention relates to Internet Protocol (IP) 
networks and to a system that generates composite 
packets for transmission over the IP network, where an 
aggregation of packets from multiple sources of higher 
layer protocols forms a single packet of the underlying 
protocol in order to maximize the data transfer efficiency 
across the IP network. When user data traverses the 
protocol stack in preparation to be sent across the IP 
network, multiple protocol headers are added to the da- 
ta. Network performance is optimized when the resulting 
packet almost completely fills the Maximum Transfer 
Unit (MTU) along the data transfer path, reducing head- 
er overhead. The system for generating composite 



packets eliminates the tradeoff between network effi- 
ciency and quality of service. The use of composite 
packets reduces the overhead associated with sending 
packets that carry only a single higher layer payload. It 
also enables individual applications to utilize small pack- 
ets at their own protocol layers with minimal penalty in 
latency, thereby freeing application developers from the 
need to maintain larger packet sizes. Implementation of 
this optimization can be carried out at a variety of pro- 
tocol layers, and aggregating packets at a particular pro- 
tocol layer does not affect the operation of any other lay- 
er. The higher layer packets aggregated into the com- 
posite packet must have the same destination. 
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Description 

Field Of The Invention 

[0001] This invention relates to Internet Protocol (IP) 
networks and, in particular, to a system which generates 
composite packets of data traffic for transmission over 
the IP network, where an aggregation of packets from 
multiple sources of higher layer protocols forms a single 
packet of the underlying protocol in order to maximize 
the data transfer efficiency across the IP network. 

Problem 

[0002] When user data traverses the protocol stack in 
preparation to be sent across the IP network, multiple 
protocol headers (e.g., RTP, UDP, IP) are added to the 
data. Network performance is optimized when the re- 
sulting packet almost completely fills the Maximum 
Transfer Unit (MTU) along the data transfer path, reduc- 
ing header overhead. However, this confronts designers 
of real-time applications, such as voice-over- IP, with a 
dilemma: waiting for data size close to MTU results in 
significant latency and thus poor quality of service, yet 
sending a small packet results in a comparatively inef- 
ficient use of bandwidth. 

Solution 

[0003] The above described problems are solved and 
a technical advance achieved in the field by the system 
for generating composite packets which functions to 
carry a variety of application traffic on a data communi- 
cation network, such as an IP network. This is accom- 
plished by the use of a composite packet structure for 
all types of traffic that is transmitted over the IP network. 
The system for generating composite packets process- 
es and converts data from multiple applications into 
transport protocol packets, and then aggregates into a 
single packet of the underlying protocol in order to max- 
imize the data transfer efficiency across the IP network, 
in this manner, applications can utilize many small pack- 
ets with minimal impact on the network performance, 
thereby freeing application developers from the need to 
maintain larger packet sizes. 

[0004] Implementation of this optimization is simple 
and can be carried out at a variety of protocol layers, 
and aggregating packets at a particular layer does not 
affect the operation of any other layer of the protocol. 
The higher layer protocol packets aggregated into a 
composite packet must have the same destination ad- 
dress to simplify routing of the resultant packet. Once a 
composite packet is sent, only the destination host 
needs to interpret the aggregation, as the intermediate 
routers pass on the IP packet normally, unaware of its 
content. This system results in the following benefits: 

1 . Faster response time for real time applications. 



2. Reduced network resource utilization. 

3. Real time application developers need not be 
concerned with packet size with regard to data 

5 transfer efficiency. 

4. Reduction in processing time by intermediate 
routers, since fewer packets need to be processed. 

10 5. Greater resiliency to data loss, since the loss of 
a packet containing a small amount of data from 
multiple sources is less disruptive than the loss of 
a packet containing data from a single source. 

15 [0005] The system for generating composite packets 
implements the composite packet capability by the use 
of an enhancement in a selected layer of the underlying 
protocol, such as the IP protocol layer which enables 
the network to carry multiple UDP/TCP packets in a sin- 
gle IP packet. The existing IP header format is used and 
a new IP protocol option is added to this header by using 
the IP Options field in the I P header to indicate that mul- 
tiple UDP and/or TCP packets are carried in the IP pack- 
et. The new IP option is interpreted only by the destina- 
tion host and the intermediate routers do not process 
the option, therefore rendering the composite nature of 
the packet transparent to the IP network routers. 

Brief Description Of The Drawings 



Figure 1 illustrates in block diagram form the overall 
architecture of the system for generating composite 
35 packets and a typical system environment in which 
this is implemented; 

Figure 2 illustrates the implementation of an IP 
header with the IP Options field indicating the mul- 
40 tiple UDP option for a packet used in the system for 
generating composite packets; 

Figure 3 illustrates the implementation of an IP 
packet used in the system for generating composite 
45 packets that carries multiple UDPs; 

Figure 4 illustrates the implementation of the IP Op- 
tions field in the IP header used in the system for 
generating composite packets that carries multiple 
50 TCPs; 

Figure 5 illustrates the implementation of the IP Op- 
tions field in the IP header used in the system for 
generating composite packets that carries multiple 
55 UDPs and TCPs; and 

Figure 6 illustrates in flow diagram form the opera- 
tion of the system for generating composite pack- 
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ets. 

Detailed Description 

[0007] Figure 1 illustrates in block diagram form the 
overall architecture of the system for generating com- 
posite packets 1 00 and a typical system environment in 
which this system is implemented. At least one, and op- 
tionally a plurality of customer equipment 111-114 are 
connected to an IP network 1 06 by means of associated 
communication media 121-124. The IP network 106 
provides the overall end-to-end routing and delivery of 
the traffic generated by the customer equipment 
1 1 1 -1 1 4 to thereby interconnect subscribers at the cus- 
tomer equipment 111-114 with desired destinations. The 
data communications originating from the customer 
equipment 111-114 include not only the traditional voice- 
only telecommunication services but also IP network- 
based multi-media services. These multi-media servic- 
es can entail any combination of media. It is therefore 
advantageous to integrate all communications into a 
single transmission medium. However, telecommunica- 
tions networks are traditionally implemented using a real 
time, circuit switched transmission medium which when 
migrating to data communications networks generate a 
large quantities of small packets. As noted above, it is 
very inefficient to transmit large quantity of small pack- 
ets over IP networks. Thus, the system for generating 
composite packets 1 00 serves as a packet originating 
host to process and combine data transmissions from 
the customer equipment 111-112 into a composite pack- 
et for transmission via the IP network 106 to a destina- 
tion host comprising the destination system for gener- 
ating composite packets 101 that serves to process the 
transport protocol packets contained in the incoming 
packet received from the IP network 106 and distribute 
to the designated destination customer equipment 
113-114. Each of the system for generating composite 
packets 1 00 and the destination system for generating 
composite packets 101 include transmitter 100T, 101T 
and receiver 1 00R, 1 01 R apparatus to enable the bidi- 
rectional transmission of data over the IP network 106. 
For simplicity of description, the example used herein 
describes the transmitter 100T apparatus and receiver 
101 R apparatus in detail, it is understood that the cor- 
responds transmitter 101 T apparatus and receiver 
100R apparatus operates in the same manner as the 
apparatus described. 

IP Networks 

[0008] In the IP network, several networks are con- 
nected together through the use of gateways and an in- 
ternetworking protocol. The gateways are termed "rout- 
ers" and use the internetworking protocol to hide the un- 
derlying details of the actual networks that carry the data 
transmissions in order to provide uniform service across 
diverse networks. The leading inter-networking protocol 



is referred to as TCP/IP and comprises two core proto- 
cols: Transmission Control Protocol (TCP) which is a 
connection oriented transport service, and Internet Pro- 
tocol (IP) which comprises a connectionless mode net- 
5 work service. Another internetworking protocol is re- 
ferred to as User Datagram Protocol (UDP). The IP is 
termed a connectionless mode network protocol since 
It is datagram oriented. When an entity connected to the 
network wishes to transmit data to a designated desti- 
10 nation using the IP, it transmits the data as a series of 
packets. Associated with each packet is an IP header. 
This IP header consists of, among other things, a 
Source IP address, a Destination IP address and a pro- 
tocol Identifier, indicating which transport protocol was 
is used to create the message being carried in the packet. 
The IP protocol module takes the transport protocol 
packet and encapsulates it into an IP packet, which con- 
tains all of the data necessary to deliver the packet to 
the designated destination. The destination host, upon 
receiving the packet, strips off the I P header and passes 
the transport protocol packet to the higher level protocol 
identified in the IP header. 

System for Generating Composite Packets (SGCP) 

[0009] In operation, as shown in flow diagram form in 
Figure 6, a plurality of application data arrives at the 
SGCP 100 at step 601 . The SGCP typically handles a 
plurality of application data transmissions, such as voice 
communications from a plurality of subscriber terminal 
devices 111-112. The application data transmissions 
can be voice communications, or data communications, 
such as credit card transactions, or multimedia commu- 
nications. These application data are received by re- 
ceivers 102 that terminate the communication lines 
121,122 and sent to the converters 103 of the SGCP 
100. At step 602, the converter element 103 handles 
necessary conversion from the received data streams 
to appropriate coding and transport protocol packets, 
such as TCP or UDP. At step 603, the sorter element 
1 05 of the SGCP 1 00 sorts the generated transport pro- 
tocol packets by destination IP address and stores these 
transport protocol packets in a set of output queues 
107-1 to 107-n for incorporation into a composite pack- 
et. Each of the queues 107-1 to 107-n stores transport 
protocol packets that are destined for the same destina- 
tion IP address. The assembler 104 of the SGCP 100 
at step 604 assembles multiple transport protocol pack- 
ets, which are stored in a selected queue and destined 
for the same destination IP address, into a single com- 
posite packet. The number of transport protocol packets 
that are assembled into the composite packet is limited 
(as an upper bound) by the size of the MTU -or is limited 
to some other specified size that is smaller than the size 
of the MTU. If there is not enough data to fill the MTU, 
the assembler 1 04 may wait for a specified period of 
time to assemble more packets before sending out the 
IP packet. At step 605, the assembler fills the IP Options 



25 



30 



35 



40 



45 



50 



3 



EP1 104141 A2 



5 

Field of the IP Header, including the Code, Length, and 
number of transport protocol packets. At step 606, the 
transmitter 1 08 of the SGCP 1 00 transmits the resultant 
packet to the next lower protocol layer in the SGCP 1 00 
and eventually the resultant packet is transmitted 5 
through the IP network 106 to the destination SGCP 101 
in well known fashion. The SGCP handler 109 of the 
SGCP 101 at step 607 dissembles the received com- 
posite packet into the individual packets, delivers the in- 
dividual transport protocol packets to their respective 
transport layer protocols (UDP, TCP), which are then 
processed and routed to their respective applications 
that are served by the destination SGCP 101. The 
SGCP 1 00 functions to receive application data from 
multiple user terminal devices, or multiple applications 
executing on a single user terminal device, or multiple 
applications executing on multiple user terminal devic- 
es, and to process and convert them into transport pro- 
tocol packets, then to aggregate them into a single pack- 
et of the underlying protocol. In this manner, customer 
communication applications can utilize many small 
packets with minimal cost to the network performance, 
thereby freeing application developers from the need to 
maintain larger packet sizes to maintain data transmis- 
sion efficiency. Implementation of this optimization is 
simple and can be carried out at a variety of protocol 
layers of the IP network, and aggregating subscriber 
packets at a particular layer of the I P does not affect the 
operation of any other layer. The aggregated subscriber 
packets must have the same origination and destination 
addresses to avoid the need to disassemble the packets 
in the IP network and route the packets contained there- 
in. Once the subscriber packets are collected and as- 
sembled into the composite packets, only the destina- 
tion SGCP needs to interpret the aggregation, as the 
intermediate routers pass on the IP packets normally. 
[0010] This system for generating composite packets 
for IP networks results in the following benefits: 

1 . Faster response time for real time applications. 

2. Reduced network resource utilization. 

3. Real time application developers need not be 
concerned with packet size with regard to data 
transfer efficiency. 

4. Reduction in processing time by intermediate 
routers, since fewer packets need to be processed. 

5. Greater resiliency to packet loss, since the loss 
of a packet containing a small amount of data from 
multiple sources is less disruptive than the loss of 
a packet containing data form a single source. 

Preferred Embodiment 

[0011] Figure 2 illustrates the implementation of an IP 



header with the IP Options field indicating the multiple 
UDP option for a packet used in the SGCP 1 00 and Fig- 
ure 3 illustrates the implementation of an I P packet used 
in the SGCP 100 that carries multiple UDP packets. 
[0012] The SGCP 100 provides an enhancement in 
the IP protocol layer to carry multiple UDP packets in a 
single IP packet The existing IP header format is used 
and a new IP option is added using the IP Options field 
in the IP header to indicate that multiple UDP packets 
are carried in the IP packet. The new IP option is inter- 
preted only by the destination SGCP and the intermedi- 
ate routers do not process the option. The IP Options 
field is specified in the IP header as shown in Figure 2, 
where the IP Options comprises three fields: Code 
(201), Length (202), and Number of UDPs (203). The 
Code field 201 of bits (0-7) is itself subdivided into three 
subfields: Copy, Option Class, and Option Number. The 
Copy flag is located in bit position 0 of the Code field 
and controls how routers treat options during fragmen- 
tation of the packet. When the Copy bit is set to a value 
of 1 , it specifies that the option should be copied into all 
fragments of the packet. When the Copy bit is set to a 
value of 0, it specifies that the option is only copied into 
the first fragment of the packet. Since the Multiple UDP 
Option is only interpreted by the destination SGCP, the 
Copy Flag bit is set to 0. The remaining bits of the Code 
field consist of the Option Class (bits 1-2) and Option 
Number (bits 3-7), which collectively define a unique op- 
tion number. This option number is selected to be a new 
option that indicates to the destination SGCP that the 
received packet is a composite packet containing a plu- 
rality of UDP packets from different sources. The Length 
field 202 (bits 8-15) of the IP Options indicates the length 
of the option and is set to a value of 3 and the Number 
of UDPs field 203 (bits 16-24) is set to the number of 
UDPs that are carried in the payload portion of this pack- 
et. 

[0013] Figure 3 illustrates the implementation of an IP 
packet which carries multiple UDPs. The IP software ex- 
ecuting on the source machine processes as many 
UDPs with the same destination address as possible in- 
to the single packet. Each UDP can be of variable 
length, but each UDP is padded with zero octets at the 
end to always end on a 32-bit boundary. The padding 
octets if used are counted in computing the value of the 
IP Length field, but not in calculating the value of the 
UDP length field. 

Alternate Embodiments 

[0014] Figure 4 illustrates the implementation of the 
IP Options field in the IP header used in the SGCP that 
carries multiple TCPs are encapsulated in an IP packet. 
This feature uses another IP option, termed the "multiple 
TCP option" which is similar to the multiple UDP option 
described above. The IP Options field for the multiple 
TCP option is illustrated in Figure 4. The first three fields 
in the IP options field are similar to the multiple UDP 
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option. This Multiple TCP IP Option is specified in the 
IP Options filed of the IP header as shown in Figure 2, 
where the Code bits (0-7) (field 401 ) are subdivided into 
three subfields: Copy, Option Class, and Option 
Number. The Copy flag located in bit position 0 controls 
how routers treat options during fragmentation of the 
packet. When the Copy bit is set to a value of 1 , it spec- 
ifies that the option should be copied into all fragments 
of the packet. When the Copy bit is set to a value of 0, 
it specifies that the option is only copied into the first 
fragment of the packet. Since the Multiple TCP Option 
is only interpreted by the destination SGCP, the Copy 
Flag bit is set to 0. The remaining bits of the Code field 
401 consist of the Option Class (bits 1 -2) and Option 
Number (bits 3-7), which collectively define a unique op- 
tion number. 

[001 5] This option number is selected to be a new op- 
tion that indicates to the destination SGCP that the re- 
ceived packet is a composite packet containing a plu- 
rality of TCP packets from different sources. The Length 
field (bits 8-15) (field 402) of the IP Option indicates the 
length of the option and is set to a value equal to the 
total length of fields 401 -403 plus fields 42-4M, and the 
Number of TCPs field (bits 16-24) (field 403) is set to 
the number of TCP packets that are carried in the pay- 
load portion of this packet. In addition, the length of TCP 
packets (fields 42-4M) must be included in the header 
to allow the destination SGCP to disassemble the IP 
packet. 

[001 6] Figure 5 illustrates the implementation of a typ- 
ical header used in the SGCP that carries multiple TCPs 
and UDPs in a single packet. Another alternative is the 
encapsulation of multiple TCPs and UDPs in a single 
packet. As noted above, a new IP option can be added 
to indicate the encapsulation of multiple TCPs and 
UDPs. The IP options field is illustrated in Figure 5. The 
IP Options field is specified in the IP header as shown 
in Figure 2 r where the Code bits (0-7) (field 501) are 
subdivided into three subfields: Copy, Option Class, and 
Option Number, where the Code bits (0-7) are subdivid- 
ed into three subfields: Copy, Option Class, and Option 
Number. The Copy flag located in bit position 0 controls 
how routers treat options during fragmentation of the 
packet. When the Copy bit is set to a value of 1 , it spec- 
ifies that the option should be copied into all fragments 
of the packet. When the Copy bit is set to a value of 0, 
it specifies that the option is only copied into the first 
fragment of the packet. Since the Multiple UDP & TCP 
Option is only interpreted by the destination SGCP, the 
Copy Flag bit is set to 0. The remaining bits of the Code 
field consist of the Option Class (bits 1 -2) and Option 
Number (bits 3-7), which collectively define a unique op- 
tion number. This option number is selected to be a new 
option that indicates to the destination SGCP that the 
received packet is a composite packet containing a plu- 
rality of UDP and TCP packets from different sources. 
The Length field (bits 8-15) (field 502) of the IP Option 
indicates the length of the I P Option and is set to a value 



equal to the total length of fields 501 -504 plus fields 
52-5N, and the Number of UDPs field (bits 1 6-23) (field 

503) and the Number of TCPs field (bits 24-31) (field 

504) are set to the number of UDPs and TCPs, respec- 
5 lively, that are carried in the payload portion of this pack- 
et. In addition, length of each TCP packets must be in- 
cluded in the header to allow the destination SGCP to 
disassemble the IP packet, since the TCP header does 
not include a length field. Thus, a plurality of TCP length 

10 definitions 52, 5N are specified in the header of the 
packet. To support encapsulation of multiple TCPs and 
UDPs, a new protocol value must be assigned for this 
new format and used in the "Protocol 0 field of the IP 
header. Alternatively, the value in the "Protocol" field can 
'5 be ignored when the IP options field indicates a mixed 
TCP/UDP encapsulation. 

Summary 

20 [0017] The SGCP aggregates packets from multiple 
sources into a single packet of the underlying protocol 
in order to match the MTU. The higher protocol layer 
packets aggregated into the composite packet must 
have the same origination and destination addresses. 

25 once composite packets are sent, only the destination 
SGCPs need to interpret the aggregations, as the inter- 
mediate routers pass on the composite packets normal- 
ly. 



1 . An apparatus for generating composite packets for 
transmission over an IP network, comprising: 

35 

means for receiving data from a plurality of ap- 
plications; 

means for processing said application data and 
40 converting into transport protocol packets; 

means for generating a composite packet com- 
prising a header and a payload for transmission 
over said IP network; 

45 

means for assembling a plurality of said trans- 
port protocol packets into said payload, which 
have a common destination for said transport 
protocol packets; 

50 

means for writing data into said header indica- 
tive of contents of said payload; 

means for transmitting said composite packet 
55 to said destination SGCP over said IP network; 

and 

means for SGCP handling said composite 
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packet at said destination SGCP. 

2. The apparatus of claim 1 wherein said means for 
generating composite packet comprises: 

means for sorting said transport protocol pack- 
ets as a function of a designated destination of 
said transport protocol packets; and 

means for storing said sorted transport protocol 
packets in a plurality of queues, one of said plu- 
rality of queues being allocated to store sorted 
said transport protocol packets destined for one 
of said designated destinations. 

3. The apparatus of claim 1 wherein said means for 
assembling payioad comprises: 

means for allocating a buffer to accumulate 
said sorted transport protocol packets destined 
for one of said designated destinations; and 

means for writing at least a portion of said trans- 
port protocol packets stored in one of said plu- 
rality of queues into said allocated buffer of said 
payioad. 

4. The apparatus of claim 1 wherein said means for 
assembling payioad further comprises: 

means for limiting the size of the said composite 
packet; and 

means for awaiting up to a specified time to ac- 
cumulate data. 

5. The apparatus of claim 1 wherein said means for 
writing data into said header comprises: 

means for generating data indicative of an op- 
tions field value representative of said payioad com- 
prising a composite packet. 

6. The apparatus of claim 1 wherein said means for 
writing data into said header further comprises: 

means for generating data indicative of the 
number of transport protocol packets contained in 
the said payioad of said composite packet. 

7. The apparatus of claim 1 wherein said means for 
writing data into said header further comprises: 

means for generating data indicative of the 
length of each of said transport protocol packets 
contained in said payioad of said composite packet. 

8. The apparatus of claim 1 wherein said means 
SGCP handling comprises: 

means for processing said header of said com- 



posite packet; 

means for disassembling said composite pack- 
et at said destination SGCP; 

5 

means for delivering individual transport proto- 
col packets to their respective transport layer; 

means for processing said transport protocol 
10 packets; and 

means for delivering to their respective appli- 
cations. 

*5 9. A method for generating composite packets for 
transmission over an IP network, comprising the 
steps of: 

receiving data from a plurality of applications; 

20 

processing said application data and convert- 
ing into transport protocol packets; 

generating composite packet comprising a 
25 header and a payioad for transmission over 

said IP network; 

assembling plurality of said transport protocol 
packets into said payioad, which have a corn- 
so mon destination for said transport protocol 
packets; 

writing data into said header indicative of con- 
tents of said payioad; 

35 

transmitting said composite packet to said des- 
tination SGCP over said IP network; and 

SGCP handling said composite packet at said 
40 destination SGCP. 

10. The method of claim 9 wherein said step of gener- 
ating composite packet comprises: 

45 sorting said transport protocol packets as a 

function of a designated destination of said 
transport protocol packets; and 

storing said sorted transport protocol packets 
50 in a plurality of queues, one of said plurality of 

queues being allocated to store sorted trans- 
port protocol packets destined for one of said 
designated destinations. 

55 11. The method of claim 9 wherein said step of assem- 
bling payioad comprises: 

allocating a buffer to accumulate said sorted 
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transport protocol packets destined for one of 
said designated destinations; and 

writing at least a portion of said transport pro- 
tocol packets stored in one of said plurality of 
queues into said allocated buffer of said pay- 
load. 

12. The method of claim 9 wherein said means for as- 
sembling payload further comprises: 

limiting the size of the said composite packet; 
and 

awaiting up to a specified time to accumulate 
data. 

13. The method of claim 9 wherein said step of writing 
data into said header comprises: 

generating data indicative of an option field 
value representative of said payload comprising a 
composite packet. 

14. The method of claim 9 wherein said step of writing 
data into said header further comprises: 

generating data indicative of the number of 
transport protocol packets contained in said pay- 
load of said composite packet. 

15. The method of claim 9 wherein said step of writing 
data into said header further comprises: 

generating data indicative of the length of 
each of said transport protocol 
packets contained in said payload of said compos- 
ite packet. 

16. The method of claim 9 wherein said step of SGCP 
handling comprises: 

processing said header of said composite 
packet; 

disassembling said composite packet at said 
destination SGCP; 

delivering individual transport protocol packets 
to their respective transport layer; 

processing said transport protocol packets; and 

delivering to their respective applications. 

17. An apparatus for generating composite packets for 
transmission over an IP network, comprising: 

receiver means for receiving data from a plural- 
ity of applications; 



converter means for converting said application 
data into transport protocol packets; 

packet sorting means sorting said transport 
5 protocol packets as a function of a designated 

destination of said transport protocol packets; 

queuing means for storing said sorted transport 
protocol packets in a plurality of queues, one of 
10 said plurality of queues being allocated to store 

sorted transport protocol packets destined for 
one of said designated destinations; 

packet generating means for producing a pack- 
1 5 et comprising a header and a payload for trans- 

mission over said IP network; 

payload assembling means for assembling plu- 
rality of said transport protocol packets into said 
20 payload, which have a common destination for 

said transport protocol packets; 

header writing means for writing data into said 
header indicative of contents of said payload, 
25 including: 

option designation means for generating 
data indicative of an option field value repre- 
sentative of said payload comprising a compos- 
ite packet; and 

30 

SGCP handling means for processing header 
of said composite packet, disassembling said 
composite packet, delivering individual trans- 
port protocol packets to their respective trans- 
35 port layer protocols for further processing, and 

eventually to their respective applications. 

18. The apparatus of claim 17 wherein said means for 
assembling payload comprises: 

40 

buffer allocation means for allocating a buffer 
to accumulate said sorted transport protocol 
packets destined for one of said plurality of des- 
tinations; and 

45 

data transfer means for writing at least a portion 
of said transport protocol packets stored in one 
of said plurality of queues into said allocated 
buffer of said payload. 

50 
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APPLICATION OATA ARRIVE AT SGCP 






CONVERTER CONVERTS APPLICATION DATA TO APPROPRIATE 
TRANSPORT PROTOCOL PACKET FORMAT 






SORTER SORTS TRANSPORT PROTOCOL PACKETS BY 
DESTINATION IP ADDRESS 







ASSEMBLER ASSEMBLES MULTIPLE TRANSPORT PROTOCOL PACKETS 
DESTINED TO THE SAME IP ADDRESS INTO A SINGLE COMPOSITE 
PACKET. THE NUMBER OF TRANSPORT PROTOCOL PACKETS ASSEMBLED 
IS LIMITED BY THE SEE OF THE MTU (OR OTHER SPECIFIED SEE 
SMALLER THAN THE SEE OF THE MTU). IF THERE IS NOT ENOUGH DATA 
TO RLL THE MTU, IT MAY WAIT FOR A SPECIFIED PERIOD OF TIME 
(TUNABLE) TO ASSEMBLE MORE PACKETS BEFORE SENDING OUT THE 

COMPOSITE PACKET 



ASSEMBLER FILLS THE IP OPTIONS FIELD OF THE IP HEADER INCLUDING 
THE CODE, THE LENGTH, THE NUMBER OF TRANSPORT PROTOCOL PACKETS, 
ETC. (REFER TO FIGURE 2, 4, AND 5) 



TRANSMITTER TRANSMITS THE RESULTANT COMPOSITE PACKET TO THE 
NEXT LOWER PROTOCOL LAYER AND EVENTUALLY THE COMPOSITE PACKET 
GOES OUT TO THE IP NETWORK AND ARRIVES AT THE DESTINATION 



SGCP HANDLER AT THE DESTINATION SGCP DISASSEMBLES THE COMPOSITE 
PACKET AND DELIVERS THE INDIVIDUAL TRANSPORT PROTOCOL PACKETS TO 

THEIR RESPECTIVE TRANSPORT LAYER PROTOCOLS (e.g., UDP, TCP) FOR 
FURTHER PROCESS AND THEN DELIVERS TO THEIR RESPECTIVE APPLICATIONS 
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(54) System for generating composite packets 

(57) This invention relates to Internet Protocol (IP) 
networks and to a system that generates composite 
packets for transmission over the IP network, where an 
aggregation of packets from multiple sources of higher 
layer protocols forms a single packet of the underlying 
protocol in order to maximize the data transfer efficiency 
across the IP network. When user data traverses the 
protocol stack in preparation to be sent across the IP 
network, multiple protocol headers are added to the da- 
ta. Network performance is optimized when the resulting 
packet almost completely fills the Maximum Transfer 
Unit (MTU) along the data transfer path, reducing head- 
er overhead. The system for generating composite 



packets eliminates the tradeoff between network effi- 
ciency and quality of service. The use of composite 
packets reduces the overhead associated with sending 
packets that carry only a single higher layer payload. It 
also enables individual applications to utilize small pack- 
ets at their own protocol layers with minimal penalty in 
latency, thereby freeing application developers from the 
need to maintain larger packet sizes. Implementation of 
this optimization can be carried out at a variety of pro- 
tocol layers, and aggregating packets at a particular pro- 
tocol layer does not affect the operation of any other lay- 
er. The higher layer packets aggregated into the com- 
posite packet must have the same destination. 
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